The invention relates generally to computer systems, and deals more particularly with a technique to route message packets.
Digital communication today often uses protocols such as TCP/IP in which a message is divided into packets. Each of the packets includes a portion of the message along with a header that indicates a destination and sequence number of the packet in the message. The packets are routed from a source node via one or more intermediary firewalls and routers to the destination node. The source node may reside in a network protected by the firewall to filter out unwanted messages. In such a case, the firewall is located between the network which it protects and the Internet or other routers and network(s) leading to the destination node. For firewall load balancing, high availability and other purpose, there may be two or more firewalls for a single network. There are often many possible routes (i.e. series of routers) between the source node or source network and the destination node or destination network.
With an asynchronous routing protocol such as TCP/IP, it is common for the request message packets to traverse one route from the source to the destination, and the response message packets to traverse a different route from the destination to the source. Each route is typically based on a routing table within each router and firewall. In such cases where there is an asynchronous routing protocol and more than one firewall for the source node or source network, it is possible for the request message packets to exit the network through one firewall for the source, and the response message packets to arrive at another firewall for the source.
In the TCP/IP protocol, when the request message packets exit the source node or source network via one of the firewalls, this firewall records a session ID under which the request message packets are being sent. The response message packets will include the same session ID. However, if the response message packets arrive at another firewall, even another firewall for the source node or source network of the original message packets, this other firewall may not recognize the response message session ID. In such a case, this other firewall will not forward the response message packets to the source node or source network of the request message packets.
FIG. 1 illustrates a prior art example of the foregoing problem. A user on user/source computer 10 creates a request message packet 13 with source IP address 10.0.0.4 and destination IP address 10.1.1.5. In this standard naming convention, “10.0.0” represents network 12 on which user computer 10 resides, and “.4” represents user computer 10. Likewise, “10.1.1.” represents network 21 on which destination server 22 resides, and “.5” represents destination server 22. There is a message routing table within user computer 10, based on the configuration of user computer 10, which sends this message packet to Virtual Routing Redundant Protocol (“VRRP”) address 10.0.0.1. This VRRP address is the virtual IP address of either firewall 14 or firewall 15, determined as follows. Firewalls 14 and 15 previously negotiated between themselves as to which one will handle/route message packets with VRRP 10.0.0.1. If that firewall 14 or 15 goes down (and does not respond to a “heartbeat” message sent from the other firewall), then the other firewall will handle the message packet with VRRP virtual address 10.0.0.1 or 10.1.1.X. In the illustrated example, firewall 14 is currently the “active” firewall (as between firewalls 14 and 15) configured to receive message packets with VRRP virtual addressed 10.0.0.1 or 10.1.1.X. So, firewall 14 receives the request message packet from user computer 10. Before forwarding the request message packet toward destination server 22, firewall 14 records “state” information about the message packet. This state information comprises session ID, packet sequence number, source IP address and destination IP address. The session ID is the identity of the session opened by user computer 10 to send the request message packets and receive the response message packets. A single message may have been divided into multiple packets, so the packet sequence number identifies the position of each packet in the message. In TCP/IP, the session remains active under normal operating conditions until the firewall 14 receives the complete response message from the destination server. (However, if the destination server does not respond within a predetermined amount of time, the session will time-out.) Firewall 14 has a table which specifies a path to the destination IP address or at least the next hop router or firewall to send the message packets toward the destination IP address. This table can be compiled using well known OSPF, RIP, EIGRP, IGRP, BGP, STATIC or IS-IS routing protocol. In the illustrated example, the table indicates that router 16 is the next hop router, so firewall 14 sends the request message packet to router 16. Likewise, router 16 has a table which specifies a path to the destination IP address or at least the next hop router or firewall to send the message packets toward the destination IP address. This table can also be compiled using OSPF, RIP, EIGRP, IGRP, BGP, STATIC or IS-IS routing protocol. In the illustrated example, the table indicates that router 18 is the next hop router, so router 16 sends the request message packet to router 18. Likewise, router 18 has a table which specifies a path to the destination IP address or at least the next hop router or firewall to send the message packets toward the destination IP address. This table can also be compiled using OSPF, RIP, EIGRP, IGRP, BGP, STATIC or IS-IS routing protocol. In the illustrated example, the table indicates that firewall 20 is the next hop firewall, so router 18 sends the request message packet to firewall 20. Likewise, firewall 20 has a table which specifies a path to the destination IP address. This table can also be compiled using OSPF, RIP, EIGRP, IGRP, BGP, STATIC or IS-IS routing protocol. In the illustrated example, the table indicates that firewall 20 can send the message packet directly to the destination IP address, i.e. IP address 10.1.1.5 of destination server 22, so firewall 20 sends the message packet to destination server 22.
Each message packet includes one or more of the following parameters:
                SIN—indicates that the message is an original request, such as a request for information or action, not a response to another message.        FIN—indicates that the sender is finished with the connection, so the session can be terminated.        RST—is a request to reestablish the connection because something has gone wrong with the original connection.        ACK—is a (response) acknowledgment that the request message packet was received.        Session ID—is the identification of the session and is included in all message packets, both those from user computer 10 to server 22, and those from server 22 to user 10.        SINACT—indicates that the packet is a response message packet, and contains part or all of the data responsive to the complete request message. This is the data generated by the destination server after it receives and handles the complete message received from the user computer. By way of example, the data can be a web page in the case where destination server is a web server.The following illustrates an example according to a prior art return routing which illustrates the problem with the prior art. The message sent from user computer 10 passed through firewall 14, so firewall 14, not firewall 16, recorded the state information. After the request message packet was forwarded to destination server 22 via router 14, router 16 and firewall 20, destination server 22 creates a responsive message. This responsive message comprises a number of message packets each with source IP address 10.1.1.5 and destination IP address 10.0.0.4. There is a message routing table within the server computer 22, based on the configuration of server computer 22, which sends each message packet to Virtual Routing Redundant Protocol (“VRRP”) address 10.1.1.1. This VRRP address is the virtual IP address of either firewall 20 or firewall 24, determined as follows. Firewalls 20 and 24 previously negotiated between them as to which one will handle/route message packets with VRRP 10.1.1.1, as long as this firewall is active. However, if the designated firewall goes down (and does not respond to a “heartbeat” message sent from the other firewall), then the other firewall will handle the message packet with VRRP virtual address 10.1.1.1. In the illustrated example, firewall 20 is currently the active firewall (as between firewalls 20 and 24) and is configured to receive message packets with VRRP virtual addressed 10.1.1.1. So, firewall 20 receives the message packet from server computer 22.        
As explained above, firewall 20 has a routing table which specifies a routing path to the response-destination IP address (i.e. the IP address of computer 10) or at least the next hop (router or firewall) to send the response message packets toward the response-destination IP address (i.e. the IP address of computer 10). This table can be compiled using well known OSPF, RIP, EIGRP, IGRP, BGP, STATIC or IS-IS routing protocol. In the illustrated example, the table indicates that router 18 is the next hop router, so firewall 20 sends the message packet to router 18. Likewise, as explained above, router 18 has a table which specifies a path to the response-destination IP address or at least the next hop (router or firewall) to send the message packet toward the response-destination IP address. This table can also be compiled using OSPF, RIP, EIGRP, IGPP, BGP, STATIC or IS-IS routing protocol. In the illustrated example, the table indicates that router 28 is the next hop router, so router 18 sends the message packet to router 28. (It may be the case that the communication path from router 18 to router 16 is down or congested, or for some other reason slower than the path to router 28, so the table in router 18 selects router 28 as the next hop.) Likewise, router 28 has a table which specifies a path to the response-destination IP address or at least the next hop (router or firewall) to send the message packets toward the destination IP address. This table can also be compiled using OSPF, RIP, EIGRP, IGRP, BGP, STATIC or IS-IS routing protocol. In the illustrated example, the table indicates that firewall 15 is the next hop firewall, so router 28 sends the message packet to firewall 15.
As noted above, firewalls 14 and 15 are both “stateful”; for security reasons they restrict handling and forwarding of certain response message packets to those with session IDs known to the firewall based on handling of the request message packets. In a restrictive example, firewall 15 will only handle and forward responsive-type message packets which are a response to message packets that previously resulted from a session with user computer 10 where the firewall 15 knows of the session. In many cases this is too restrictive, so firewalls 14 and 15 can be configured as stateful for certain types of response messages, but not others. For example, response message packets sent to certain applications within user computer 10 may be limited based on session IDs known to the firewall which receives the response message packet, but response message packets sent to other applications within user computer 10 may not be so limited by their session ID. In either scenario, whenever firewall 14 or 15 receives a message packet that does not include a SIN, FIN, RST or ACK indicator, the firewall assumes the message packet is a response to a request message sent previously. So, firewall 15, upon receipt of the response message packet, checks its list of session IDs of active sessions, to determine if firewall 15 forwarded the previous, corresponding request message packets. If so, i.e. the stateful firewall 15 has a record of this session ID, and the firewall 15 will forward it to the next hop, in this case user computer 10. However, in the illustrated example, the stateful firewall 15 does not have a record of this session ID (because the original request message packet from user computer 10 went through firewall 14), so firewall 15 will discard the message packet, i.e. erase it and not forward it to user computer 10 or anywhere else. Consequently, user computer 10 does not receive this responsive message packet from server computer 22.
It was previously known for each firewall of a firewall cluster to notify the other firewalls in the cluster of every session of which it learns through receipt of an outbound/request message packet. Consequently, if a responsive message packet arrives at a stateful firewall which did not handle the outbound/request message packets, this firewall will still recognize the session, so the firewall can accept the message packet and forward it to the destination.
For some applications, where uniform quality of service is required, it is desirable for all the packets of a message to follow the same or nearly the same path from a source to a destination, to the extent the path is available. However, the routing tables in the firewalls and routers will continually strive to select the fastest path and will avoid routers and firewalls which are down or congested. While the fastest path may be desirable in many circumstances, for uniform quality of service, path consistency may be preferred.
It was also previously known to attempt to cause a response message packet to follow the same path used by the outbound/request message. However, in some cases, one or more routers or firewalls in this path are unavailable, so it is not possible for the response message to follow the same path used by the outbound/request message. In such a case, a TCP/IP communication program which utilizes the VRRP protocol will learn of the failure of this device when the failed device does not respond to its periodic hello message. Then, the TCP/IP communication program will update its routing tables accordingly to prevent the message from being sent to the failed device again (unless the failed device responds to a subsequent hello message).
An object of the present invention is to provide a system, method and program to route response message packets along a same or similar path as used by the outbound/request message packets in the same session to the extent practical.